滴滴开源DRouter：一款高效的Android路由框架
桔妹导读：DRouter是滴滴乘客端自研的一套Android路由框架，基于平台化解耦的思想，为组件间通信服务。该项目以功能全面、易用为原则，支持各种路由场景，在页面路由、服务获取和过滤、跨进程及跨应用、VirtualApk插件支持等方面都能提供多样化的服务。目前已在滴滴乘客端、顺风车、单车、国际化、滴滴定制车等十多个滴滴的app内使用，得到各种场景的验证。
DRouter支持的功能
使用URI字符串导航Activity、Fragment、View、RouterHandler，支持正则表达式
回调式onActivityResult
RouterHandler、Activity支持等待异步完成(hold)，并可设置超时时间
RouterHandler指定执行线程
注入拦截器，支持全局拦截器和局部拦截器，面向切面编程
更为多样化的Fragment页面跳转能力
使用接口或基类导航到实现类Service的Class以及实例
支持Service别名以及多维过滤器查找
导航Service可指定任意构造器、支持单例
支持动态注册RouterHandler、Service，绑定生命周期自动解绑
简单易用的跨进程执行RouterHandler、Service
跨进程访问无需提前绑定、如同本地调用一样进行访问
支持客户端进程和服务端进程自动重连
支持VirtualApk
滴滴乘客端包容万象，拥有众多的业务和组件，早在15年就已经启动组件化重构。使用滴滴自研的基于JavaSPI插件技术，动态的生成从接口到实现的映射关系，完成了组件化的通信功能，并且应用到了整个滴滴的Android体系中。虽然SPI性能优良、使用便捷，但同时功能单一、支持的场景少也是一直存在的问题。随着组件化实践的常态化，急需要一款功能强大，适合滴滴的场景，定制化程度高的路由框架。
目前市面上已经存在几款路由框架了，比如ARouter，WMRouter。不过滴滴业务繁多，平台化遍布各种场景，对路由的定制化需求强烈，很多功能市面上的路由是不支持的，比如：
ARouter作为路由的先行者，由于开发较早，功能简单、同时路由查找过程性能损耗较大
WMRouter在路由的性能上仍然有一定优化空间，同时没有导航到Fragment/View、回调式ActivityResult，使用ServiceLoader稍显繁琐且无法动态注册以及多维过滤
现今没有一款路由框架对完整的跨进程和跨应用有较好的支持，这在滴滴定制车团队有着强诉求
同时没有一款路由对Fragment提供更多的扩展能力，DRouter在鸿鹄和车载屏项目以及更多Fragment的场景可以提供支持
基于以上问题，从18年开始自研了DRouer路由框架，为滴滴的平台化服务几十种场景。
路由表在编译期通过插件动态生成。插件会启动多线程同时异步处理所有的组件；增量扫描功能可以帮助开发者在第二次编译时，只对修改过的代码进行处理，极大地缩短路由表生成的时间。
在本人的开发机上测试，19年滴滴乘客端扫描5.5万个类，全量需要不到6s的时间；如果是修改了application模块，增量扫描只需要处理修改的单类，耗时0.4s时间；如果是修改了library组件，增量扫描需要扫描整个jar包，根据jar包的大小时间会稍多一些，例如滴滴专快组件增量耗时3.9s。
另外框架初始化的时候启动子线程去加载路由表，不阻塞主线程的执行，尽其所能提高效率。
支持使用URI字符串导航Activity、Fragment、View、RouterHandler，支持正则表达式、回调式onActivityResult、拦截器；
RouterHandler还支持异步完成（不阻塞）、指定执行线程等等；
同时针对Fragment，支持单Page、栈Page、ViewPager三种形式的Fragment加载。
▍3 强大的ServiceLoader能力
DRouter同样是基于SPI的理念，路由表会生成接口或基类对实现类的映射。
获取实例时可以指定执行任意构造器、单例、优先级排序、自动拆解所有接口和基类作为key
可以通过alias，以及任意数量多的维度对目标进行多维过滤
动态注册
▍4 像调用本地方法一样跨进程通信和回调
无需编写繁琐的aidl文件实现跨进程调用，使用方式几乎等同本地导航RouterHandler和Service，只需增加一些配置即可。
不需要异步去bindService等待，同步执行
支持跨应用
替代反射，服务端使用本地方法执行，提高执行效率
支持任意类型的对象跨进程传递，包括Context、自定义类，支持RemoteCallback回调
服务端异常崩溃重启后，客户端按需自动重新执行已发送的跨进程命令。
▍5 框架内部尽可能减少使用反射，提升性能
加载路由表、实例化路由元素、以及跨进程命令到达服务端后的分发这些常规应该使用反射的场景，使用预占位或动态生成代码来替换成java的new创建和显式方式执行，最大限度的去避免反射执行，提高性能。
考虑到功能的全面性，使用ServiceLoader时如指定非默认构造函数以及跨进程时传递自定义类，在框架内部会使用到反射，不过可以使用默认构造函数以及对跨进程对象实现Parcelable来避免。
▍6 动态下载与api匹配的plugin，自升级
很多项目包括DRouter需要搭配gradle插件和java依赖来使用，正常来讲升级java依赖时大概率需要同时升级gradle插件，这在滴滴这种业务线繁多，各业务线除了有自己的组件同时又有自己的壳工程场景是一个非常痛的点。当业务线的组件因平台的同学在公共层升级了java依赖后，但又没有同时手动更新自己业务壳工程的gradle插件，大概率就会编译失败。
DRouter利用plugin-proxy壳插件来解决这个问题，壳插件会在编译期自动检查java依赖的版本，同时获得应该匹配的插件版本。接着plugin-proxy会去下载这个匹配的gradle插件，并最终执行。这样就解决了因升级java依赖而gradle插件不匹配导致的编译问题。
▍7 无需手动添加混淆规则
DRouter把混淆规则隐藏到了java依赖里，当启用混淆功能时会自动应用混淆规则。这样即使升级了DRouter版本也无需关心混淆规则是否需要升级。
整体架构分三层，自下而上是数据流层、组件层、开放接口层。
4.1 数据流层
数据流层是DRouter最重要的核心模块，这里承载着插件生成的路由表、路由元素、动态注册、以及跨进程功能相关的序列化数据流。所有的路由流转都会从这里取得对应的数据，进而流向正确的目标。
4.2 组件层
这一层是功能组件层，核心的路由分发、拦截器、生命周期、异步暂存和监控、ServiceLoader、多维过滤、Fragment路由，以及跨进程命令打包等。
4.3 开放接口层
DRouter在接口层做了大量的精简和优化，在灵活性和易用性方面做了很多权衡，主要目的是减少冗余API，使框架更为简单的使用和接入。比如Request和ServiceLoader作为最核心的API方法数非常少，一些不常用的功能会放到Extend中。
路由数据流从创建Request开始，通过URI在路由表中找出所有的结点，会按照RouterHandler、UI的顺序以及优先级顺序执行。每一个元素都可以定义自己的拦截器，这里的拦截器必须放行以后才能执行对应的结点；同时对于RouterHandler执行完又可以决定是否拦截后面所有的结点。当所有的结点执行完，且异步暂存态也都已释放，最终把结果回传给请求处。
▍ServiceFlow
ServiceLoader既可以获取Class也可以获取对象实例，核心是路由表和过滤器，其中FeatureMatcher拥有多维过滤的功能。像滴滴这种多业务场景的应用，在使用MVP架构时对P的匹配至少会需要根据所在国家、订单业务线、订单状态三个维度来分别对应唯一的Presenter，多维过滤就很容易解决这个问题。性能方面，对象实例化会根据构造器类型，利用插件生成的RouterProxy代码通过new来实例化无参对象（默认构造）或者反射实例化有参对象（非默认构造）。
▍RemoteFlow
DRouter的跨进程功能是一大特色，左侧绿色代表客户端，自上而下会把所有的参数打包成命令，这里支持任意类型，框架内有一套完整的机制通过遍历集合、转换、组装，最后存储到Parcel里。利用Authority查找到服务端的Provider并随之利用此通道返回服务端的Binder。
在服务端，也就是右侧的紫色，会自下而上把命令解包和分发。然后利用DRouter的路由RouterHandler和ServiceLoader的功能，使得客户端的命令最终在服务端执行。插件会在服务端生成一段代码，这段代码可以避免使用反射，提高整体的执行效率。
整个过程同步执行，使用简单、高效。
DRouter是一套功能完善、定制化程度高的路由框架，具有易于上手、架构清晰、性能优良的特点。现已成为滴滴不可或缺的基础组件之一。DRouter作为组件化方案的践行者，将继续提升各个场景的支持能力，也欢迎各位开发者使用并提出宝贵的反馈意见。
GitHub开源地址：
https://github.com/didi/DRouter
开源作者
▬